The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
Internet protocol television (IPTV) is a brand new media of customized interactive services based on internet technology. Broadcast TV (BTV) is the very basic service in an IPTV system and the most matured service in the industry. In consideration of program forecasts, brand advertisements and commercials, operators usually set a default switch-on channel to broadcast program forecasts, brand advertisements and commercials so that the contents broadcast through the default switch-on channel are received as soon as an IP set-top box (STB) is powered on. The default switch-on channel is usually set on Channel 1.
BTV is a multicast-based service and is dependent of multicast route protocol, internet group management protocol (IGMP) and IGMP Proxy protocol etc. which are supported by network devices. When an IPTV system transmits multicast program flows to an access network, routers in the network usually comply with multicast route protocol and network devices in the access network comply with IPMP Proxy protocol.
An IP STB is a user terminal device in an IPTV system and the storage in the IP STB usually stores a channel list which contains the multicast IP addresses, multicast port numbers and other channel related information of the channels that a user is authorized to view. When a user is receiving a BTV service, his IP STB first searches for the multicast address and multicast port number of the channel that the user wants to watch from the channel list according to the instruction from a remote controller, then the IP STB composes an IGMP Report message according to the requirements of REC2236, and applies to join a corresponding multicast group, and finally the IP STB receives the multicast flow from an IPTV service source network after network devices of all levels have performed IGMP Proxy protocol.
When the user wants to switch to another channel, the IP STB first composes an IGMP Leave message according to the requirements of RFC2236 to leave the current multicast group, hence the transmission of the multicast flow of the current channel is ceased; then the IP STB searches for the multicast address and multicast port of the channel that the user wants to watch from the channel list and composes an IGMP Report message according to the requirements of RFC2236 to join a corresponding new multicast group, then the multicast flow of the new channel is transmitted to the IP STB.
When the IP STB switches from BTV service to another service, the IP STB first composes an IGMP Leave message according to the requirements of RFC2236 to leave the current multicast group, hence the transmission of the multicast flow of the current channel is ceased; then the IP STB sends a corresponding report according to the instruction from the user to obtain a new service.
When an IP STB in the prior art needs to restart due to malfunction (sudden power breakdown, mis-pressing the power button by man, etc.) while carrying out BTV service, the technical solution in the prior art is sending an IGMP Report message to join the multicast group of the default switch-on channel of BTV service directly after the IP STB is powered on, no matter whether the multicast flow which was transmitted when the malfunction occurred has been ceased.
At the very moment when such malfunction occurs, the IP STB is not able to send an IGMP Leave message to leave the current multicast group. Meanwhile, there is a very small probability of the current multicast group being the default switch-on channel, and the probability equals to 1/total number of BTV programs that a user is authorized to watch.
When the IP STB switches on and directly sends an IGMP Report message to join the multicast group of the default switch-on channel, the multicast flow which was transmitted when the malfunction occurs is usually still transmitted to the IP STB, because the digital subscriber line access multiplexer (DSLAM) which sends the multicast flow to the IP STB is unable to learn the situation of the IP STB when the IP STB malfunctioned. In practical applications, a DSLAM has to send an IGMP general query and a group-specific query to make sure whether an IP STB in the current multicast group is active.
RFC2236 defines that the interval for IGMP Query message is 125 seconds and the maximum response time to an IGMP Query message is 10 seconds. RFC2236 does not define how long a device should wait, after a general query is transmit, and then transmit a group-specific query (the interval length varies with devices from different manufacturers, usually a group-specific query is sent 20 seconds after an IGMP Query message is sent) or the number of sending times and interval length of group-specific queries (devices from different manufacturers make different settings, usually a group-specific query is sent twice with an interval of 4 seconds).
If the IP STB malfunctions after the DSLAM has sent an IGMP Query message and before the IP STB returns a corresponding response message, the DSLAM will send the IGMP Query message once again and further send a group-specific query twice to check whether the multicast group member which malfunctions has left the multicast group; then the DSLAM will cease the transmission of the multicast flow which is transmitted to the IP STB when it malfunctions. That is to say, if the IP STB malfunctions after the DSLAM has sent a general query and before the IP STB returns a corresponding report, the transmission of the multicast flow which is transmitted to the IP STB when the IP STB malfunctions will continue for about 144 seconds.
If the IP STB malfunctions when the DSLAM sends an IGMP Query message and the IP STB returns a corresponding response message, the DSLAM will send IGMP Query message twice again and further send a group-specific query twice to check whether the multicast group member which malfunctions has left the multicast group; then the DSLAM will cease the transmission of the multicast flow which is transmitted to the IP STB when the IP STB malfunctions. That is to say, if the IP STB malfunctions when the DSLAM sends an IGMP Query message and the IP STB returns a corresponding response message, the transmission of the multicast flow which is transmitted to the IP STB when the IP STB malfunctions will continue for about 269 seconds.
It can be concluded from the above that when an IP STB malfunctions, the transmission of the multicast flow to the IP STB will continue for about 144 to 269 seconds.
Furthermore, when malfunction occurs, an IP STB needs about 20 seconds to restart, compose an IGMP Report message and apply to join the multicast group of the default switch-on channel, after that the multicast flow of the default switch-on channel will be sent to the IP STB. Obviously, this will cause the situation in which the multicast flow which the IP STB has been receiving when the IP STB malfunctions and the multicast flow of the default switch-on channel are issued to the IP STB simultaneously, and the situation is called simultaneous issuance of two multicast flows.
Simultaneous issuance of two multicast flows usually lasts 124 to 249 seconds (or 119 to 254 seconds in some extreme cases). Simultaneous issuance of two multicast flows brings in two harmful consequences: firstly, the total bandwidth of two multicast flows usually exceeds the service operation bandwidth provided for a user by an IPTV system, which results in serious package loss in the multicast flows transmitted to the IP STB, reflected in frozen motions and mosaic; secondly, as there are two multicast flows transmitted to an IP STB simultaneously, the service performance of the IP STB will be affected, which causes unsmooth playback of the IP STB at least and even abnormal restart of the IP STB.
To sum up, in the prior art two multicast flows may be issued to an IP STB simultaneously for a long time, which seriously degrades picture quality and may even cause the IP STB to restart abnormally. This will influence user experience to a great extent and decrease user satisfaction.